| Package | hl7.ehrs.ehrsfmr21 |
| Type | Requirements |
| Id | Id |
| FHIR Version | R5 |
| Source | http://hl7.org/ehrs/https://build.fhir.org/ig/mvdzel/ehrsfm-fhir-r5/Requirements-EHRSFMR2.1-CPS.2.2.html |
| Url | http://hl7.org/ehrs/Requirements/EHRSFMR2.1-CPS.2.2 |
| Version | 2.1.0 |
| Status | active |
| Date | 2024-11-26T16:30:50+00:00 |
| Name | CPS_2_2_Support_externally_sourced_Clinical_Data |
| Title | CPS.2.2 Support externally-sourced Clinical Data (Function) |
| Experimental | False |
| Realm | uv |
| Authority | hl7 |
| Description | Incorporate discrete clinical data from external sources and support communication/presentation of data captured from medical and non-medical devices and entities. |
| Purpose | Mechanisms for incorporating external clinical data (including identification of source) are available and communication with non-medical devices and entities is supported as appropriate to the care setting such as an office or a patient's home. Externally-sourced data may be presented with locally-sourced documentation and notes wherever appropriate. This covers all types of data received by the provider that would typically be incorporated into a medical record, including but not limited to faxes, referral authorizations, consultant reports, and patient/resident correspondence of a clinical nature. Intrinsic to the concept of electronic health records is the ability to exchange health information with other providers of health care services. Health information from these external sources needs to be received, stored in the patient record, and displayed upon request. Examples of externally-sourced data and documents include: - Laboratory results received through an electronic interface. This information is received and stored in the resident record as discrete data, which means that each separate element of the data needs to be stored in its own field. Therefore, if laboratory results are received through an electronic interface, the results are received in the EHR and the laboratory test name, result (value), and unit of measure are correctly displayed as discrete data (instead of in report or summarized format). - Scanned documents received and stored as images (e.g., power of attorney forms or living wills). These scanned documents are indexed and can be retrieved, e.g., based on the document type, date of the original document, and the date of scanning. - Text-based outside reports (e.g., x-ray reports, hospital discharge summaries or history and physical examinations). Any mechanism for capturing these reports is acceptable (e.g., OCR, PDF, JPG or TIFF). - Clinical images from an external source (e.g., radiographic images, digital images from a diagnostic scan or graphical images). These images may be stored within the system or be available by direct linkage to an external source (e.g., a hospital's picture archiving and communication system). - Other forms of clinical results (e.g., EKG waveforms). - Medication history from an external source such as a retail pharmacy, the patient, or another provider . While the medication history includes the medication name, strength, and SIG, this does not imply that the data will populate the medication administration module. In many systems the medication administration module is populated from the medication order rather than from the medication history. - Structured, text-based reports (e.g., medical summary text in a structured format). - Standards-based structured, codified data (such as a standards-based referral letter that contains SNOMED CT codes). Such data may be presented with locally-sourced documentation and notes wherever appropriate. |
No resources found
No resources found
Note: links and images are rebased to the (stated) source
Incorporate discrete clinical data from external sources and support communication/presentation of data captured from medical and non-medical devices and entities.
Mechanisms for incorporating external clinical data (including identification of source) are available and communication with non-medical devices and entities is supported as appropriate to the care setting such as an office or a patient's home. Externally-sourced data may be presented with locally-sourced documentation and notes wherever appropriate. This covers all types of data received by the provider that would typically be incorporated into a medical record, including but not limited to faxes, referral authorizations, consultant reports, and patient/resident correspondence of a clinical nature. Intrinsic to the concept of electronic health records is the ability to exchange health information with other providers of health care services. Health information from these external sources needs to be received, stored in the patient record, and displayed upon request.
Examples of externally-sourced data and documents include:
Laboratory results received through an electronic interface. This information is received and stored in the resident record as discrete data, which means that each separate element of the data needs to be stored in its own field. Therefore, if laboratory results are received through an electronic interface, the results are received in the EHR and the laboratory test name, result (value), and unit of measure are correctly displayed as discrete data (instead of in report or summarized format).
Scanned documents received and stored as images (e.g., power of attorney forms or living wills). These scanned documents are indexed and can be retrieved, e.g., based on the document type, date of the original document, and the date of scanning.
Text-based outside reports (e.g., x-ray reports, hospital discharge summaries or history and physical examinations). Any mechanism for capturing these reports is acceptable (e.g., OCR, PDF, JPG or TIFF).
Clinical images from an external source (e.g., radiographic images, digital images from a diagnostic scan or graphical images). These images may be stored within the system or be available by direct linkage to an external source (e.g., a hospital's picture archiving and communication system).
Other forms of clinical results (e.g., EKG waveforms).
Medication history from an external source such as a retail pharmacy, the patient, or another provider . While the medication history includes the medication name, strength, and SIG, this does not imply that the data will populate the medication administration module. In many systems the medication administration module is populated from the medication order rather than from the medication history.
Structured, text-based reports (e.g., medical summary text in a structured format).
Standards-based structured, codified data (such as a standards-based referral letter that contains SNOMED CT codes).
Such data may be presented with locally-sourced documentation and notes wherever appropriate.
| CPS.2.2#01 | SHALL |
The system SHALL provide the ability to capture and store computable data (e.g., laboratory results, telemetry, or medication details). |
| CPS.2.2#02 | SHALL |
The system SHALL provide the ability to capture and store a reference to external data. |
| CPS.2.2#03 | SHALL |
The system SHALL provide the ability to capture and store externally-sourced computable data (e.g., laboratory results, telemetry, medication details). |
| CPS.2.2#04 | SHALL |
The system SHALL provide the ability to capture and store externally-sourced standards-based structured, codified data. |
| CPS.2.2#05 | SHOULD |
The system SHOULD provide the ability to capture and store laboratory test data as discrete data elements (e.g., test name, laboratory sample status, date/time of collection, test results, original test units, laboratory panel name, pre-defined testing conditions met indicator, specimen identifier, reference range lower limit, reference range upper limit, laboratory identifier, abnormal flag, and clinical significance indicator). |
| CPS.2.2#06 | SHOULD |
The system SHOULD provide the ability to capture and store externally-sourced clinical documentation as structured data, where appropriate, including the original, updates and addenda. |
| CPS.2.2#07 | SHOULD |
The system SHOULD provide the ability to capture and store health-related data from non-medical devices (e.g., digital camera or sound recorder). |
| CPS.2.2#08 | SHOULD |
The system SHOULD provide the ability to capture the original requisition ID number associated with an order. |
FHIR{
"resourceType" : "Requirements",
"id" : "EHRSFMR2.1-CPS.2.2",
"meta" : {
"profile" : [
"http://hl7.org/ehrs/StructureDefinition/FMFunction"
]
},
"text" : {
"status" : "extensions",
"div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\">\n <span id=\"description\"><b>Statement <a href=\"https://hl7.org/fhir/versions.html#std-process\" title=\"Normative Content\" class=\"normative-flag\">N</a>:</b> <div><p>Incorporate discrete clinical data from external sources and support communication/presentation of data captured from medical and non-medical devices and entities.</p>\n</div></span>\n\n \n <span id=\"purpose\"><b>Description <a href=\"https://hl7.org/fhir/versions.html#std-process\" title=\"Informative Content\" class=\"informative-flag\">I</a>:</b> <div><p>Mechanisms for incorporating external clinical data (including identification of source) are available and communication with non-medical devices and entities is supported as appropriate to the care setting such as an office or a patient's home. Externally-sourced data may be presented with locally-sourced documentation and notes wherever appropriate. This covers all types of data received by the provider that would typically be incorporated into a medical record, including but not limited to faxes, referral authorizations, consultant reports, and patient/resident correspondence of a clinical nature. Intrinsic to the concept of electronic health records is the ability to exchange health information with other providers of health care services. Health information from these external sources needs to be received, stored in the patient record, and displayed upon request.</p>\n<p>Examples of externally-sourced data and documents include:</p>\n<ul>\n<li>\n<p>Laboratory results received through an electronic interface.\nThis information is received and stored in the resident record as discrete data, which means that each separate element of the data needs to be stored in its own field. Therefore, if laboratory results are received through an electronic interface, the results are received in the EHR and the laboratory test name, result (value), and unit of measure are correctly displayed as discrete data (instead of in report or summarized format).</p>\n</li>\n<li>\n<p>Scanned documents received and stored as images (e.g., power of attorney forms or living wills).\nThese scanned documents are indexed and can be retrieved, e.g., based on the document type, date of the original document, and the date of scanning.</p>\n</li>\n<li>\n<p>Text-based outside reports (e.g., x-ray reports, hospital discharge summaries or history and physical examinations).\nAny mechanism for capturing these reports is acceptable (e.g., OCR, PDF, JPG or TIFF).</p>\n</li>\n<li>\n<p>Clinical images from an external source (e.g., radiographic images, digital images from a diagnostic scan or graphical images).\nThese images may be stored within the system or be available by direct linkage to an external source (e.g., a hospital's picture archiving and communication system).</p>\n</li>\n<li>\n<p>Other forms of clinical results (e.g., EKG waveforms).</p>\n</li>\n<li>\n<p>Medication history from an external source such as a retail pharmacy, the patient, or another provider .\nWhile the medication history includes the medication name, strength, and SIG, this does not imply that the data will populate the medication administration module. In many systems the medication administration module is populated from the medication order rather than from the medication history.</p>\n</li>\n<li>\n<p>Structured, text-based reports (e.g., medical summary text in a structured format).</p>\n</li>\n<li>\n<p>Standards-based structured, codified data (such as a standards-based referral letter that contains SNOMED CT codes).</p>\n</li>\n</ul>\n<p>Such data may be presented with locally-sourced documentation and notes wherever appropriate.</p>\n</div></span>\n \n\n \n\n \n <span id=\"requirements\"><b>Criteria <a href=\"https://hl7.org/fhir/versions.html#std-process\" title=\"Normative Content\" class=\"normative-flag\">N</a>:</b></span>\n \n <table id=\"statements\" class=\"grid dict\">\n \n <tr>\n <td style=\"padding-left: 4px;\">\n \n <span>CPS.2.2#01</span>\n \n </td>\n <td style=\"padding-left: 4px;\">\n \n \n \n <span>SHALL</span>\n \n </td>\n <td style=\"padding-left: 4px;\" class=\"requirement\">\n \n <span><div><p>The system SHALL provide the ability to capture and store computable data (e.g., laboratory results, telemetry, or medication details).</p>\n</div></span>\n \n \n </td>\n </tr>\n \n <tr>\n <td style=\"padding-left: 4px;\">\n \n <span>CPS.2.2#02</span>\n \n </td>\n <td style=\"padding-left: 4px;\">\n \n \n \n <span>SHALL</span>\n \n </td>\n <td style=\"padding-left: 4px;\" class=\"requirement\">\n \n <span><div><p>The system SHALL provide the ability to capture and store a reference to external data.</p>\n</div></span>\n \n \n </td>\n </tr>\n \n <tr>\n <td style=\"padding-left: 4px;\">\n \n <span>CPS.2.2#03</span>\n \n </td>\n <td style=\"padding-left: 4px;\">\n \n \n \n <span>SHALL</span>\n \n </td>\n <td style=\"padding-left: 4px;\" class=\"requirement\">\n \n <span><div><p>The system SHALL provide the ability to capture and store externally-sourced computable data (e.g., laboratory results, telemetry, medication details).</p>\n</div></span>\n \n \n </td>\n </tr>\n \n <tr>\n <td style=\"padding-left: 4px;\">\n \n <span>CPS.2.2#04</span>\n \n </td>\n <td style=\"padding-left: 4px;\">\n \n \n \n <span>SHALL</span>\n \n </td>\n <td style=\"padding-left: 4px;\" class=\"requirement\">\n \n <span><div><p>The system SHALL provide the ability to capture and store externally-sourced standards-based structured, codified data.</p>\n</div></span>\n \n \n </td>\n </tr>\n \n <tr>\n <td style=\"padding-left: 4px;\">\n \n <span>CPS.2.2#05</span>\n \n </td>\n <td style=\"padding-left: 4px;\">\n \n \n \n <span>SHOULD</span>\n \n </td>\n <td style=\"padding-left: 4px;\" class=\"requirement\">\n \n <span><div><p>The system SHOULD provide the ability to capture and store laboratory test data as discrete data elements (e.g., test name, laboratory sample status, date/time of collection, test results, original test units, laboratory panel name, pre-defined testing conditions met indicator, specimen identifier, reference range lower limit, reference range upper limit, laboratory identifier, abnormal flag, and clinical significance indicator).</p>\n</div></span>\n \n \n </td>\n </tr>\n \n <tr>\n <td style=\"padding-left: 4px;\">\n \n <span>CPS.2.2#06</span>\n \n </td>\n <td style=\"padding-left: 4px;\">\n \n \n \n <span>SHOULD</span>\n \n </td>\n <td style=\"padding-left: 4px;\" class=\"requirement\">\n \n <span><div><p>The system SHOULD provide the ability to capture and store externally-sourced clinical documentation as structured data, where appropriate, including the original, updates and addenda.</p>\n</div></span>\n \n \n </td>\n </tr>\n \n <tr>\n <td style=\"padding-left: 4px;\">\n \n <span>CPS.2.2#07</span>\n \n </td>\n <td style=\"padding-left: 4px;\">\n \n \n \n <span>SHOULD</span>\n \n </td>\n <td style=\"padding-left: 4px;\" class=\"requirement\">\n \n <span><div><p>The system SHOULD provide the ability to capture and store health-related data from non-medical devices (e.g., digital camera or sound recorder).</p>\n</div></span>\n \n \n </td>\n </tr>\n \n <tr>\n <td style=\"padding-left: 4px;\">\n \n <span>CPS.2.2#08</span>\n \n </td>\n <td style=\"padding-left: 4px;\">\n \n \n \n <span>SHOULD</span>\n \n </td>\n <td style=\"padding-left: 4px;\" class=\"requirement\">\n \n <span><div><p>The system SHOULD provide the ability to capture the original requisition ID number associated with an order.</p>\n</div></span>\n \n \n </td>\n </tr>\n \n </table>\n</div>"
},
"url" : "http://hl7.org/ehrs/Requirements/EHRSFMR2.1-CPS.2.2",
"version" : "2.1.0",
"name" : "CPS_2_2_Support_externally_sourced_Clinical_Data",
"title" : "CPS.2.2 Support externally-sourced Clinical Data (Function)",
"status" : "active",
"date" : "2024-11-26T16:30:50+00:00",
"publisher" : "EHR WG",
"contact" : [
{
"telecom" : [
{
"system" : "url",
"value" : "http://www.hl7.org/Special/committees/ehr"
}
]
}
],
"description" : "Incorporate discrete clinical data from external sources and support communication/presentation of data captured from medical and non-medical devices and entities.",
"jurisdiction" : [
{
"coding" : [
{
"system" : "http://unstats.un.org/unsd/methods/m49/m49.htm",
"code" : "001",
"display" : "World"
}
]
}
],
"purpose" : "Mechanisms for incorporating external clinical data (including identification of source) are available and communication with non-medical devices and entities is supported as appropriate to the care setting such as an office or a patient's home. Externally-sourced data may be presented with locally-sourced documentation and notes wherever appropriate. This covers all types of data received by the provider that would typically be incorporated into a medical record, including but not limited to faxes, referral authorizations, consultant reports, and patient/resident correspondence of a clinical nature. Intrinsic to the concept of electronic health records is the ability to exchange health information with other providers of health care services. Health information from these external sources needs to be received, stored in the patient record, and displayed upon request.\n\nExamples of externally-sourced data and documents include:\n\n- Laboratory results received through an electronic interface. \n This information is received and stored in the resident record as discrete data, which means that each separate element of the data needs to be stored in its own field. Therefore, if laboratory results are received through an electronic interface, the results are received in the EHR and the laboratory test name, result (value), and unit of measure are correctly displayed as discrete data (instead of in report or summarized format). \n\n- Scanned documents received and stored as images (e.g., power of attorney forms or living wills). \n These scanned documents are indexed and can be retrieved, e.g., based on the document type, date of the original document, and the date of scanning. \n\n- Text-based outside reports (e.g., x-ray reports, hospital discharge summaries or history and physical examinations). \n Any mechanism for capturing these reports is acceptable (e.g., OCR, PDF, JPG or TIFF). \n\n- Clinical images from an external source (e.g., radiographic images, digital images from a diagnostic scan or graphical images). \n These images may be stored within the system or be available by direct linkage to an external source (e.g., a hospital's picture archiving and communication system). \n\n- Other forms of clinical results (e.g., EKG waveforms).\n\n- Medication history from an external source such as a retail pharmacy, the patient, or another provider . \n While the medication history includes the medication name, strength, and SIG, this does not imply that the data will populate the medication administration module. In many systems the medication administration module is populated from the medication order rather than from the medication history.\n\n- Structured, text-based reports (e.g., medical summary text in a structured format). \n\n- Standards-based structured, codified data (such as a standards-based referral letter that contains SNOMED CT codes). \n\nSuch data may be presented with locally-sourced documentation and notes wherever appropriate.",
"statement" : [
{
"extension" : [
{
"url" : "http://hl7.org/ehrs/StructureDefinition/requirements-dependent",
"valueBoolean" : false
}
],
"key" : "EHRSFMR2.1-CPS.2.2-01",
"label" : "CPS.2.2#01",
"conformance" : [
"SHALL"
],
"conditionality" : false,
"requirement" : "The system SHALL provide the ability to capture and store computable data (e.g., laboratory results, telemetry, or medication details)."
},
{
"extension" : [
{
"url" : "http://hl7.org/ehrs/StructureDefinition/requirements-dependent",
"valueBoolean" : false
}
],
"key" : "EHRSFMR2.1-CPS.2.2-02",
"label" : "CPS.2.2#02",
"conformance" : [
"SHALL"
],
"conditionality" : false,
"requirement" : "The system SHALL provide the ability to capture and store a reference to external data."
},
{
"extension" : [
{
"url" : "http://hl7.org/ehrs/StructureDefinition/requirements-dependent",
"valueBoolean" : false
}
],
"key" : "EHRSFMR2.1-CPS.2.2-03",
"label" : "CPS.2.2#03",
"conformance" : [
"SHALL"
],
"conditionality" : false,
"requirement" : "The system SHALL provide the ability to capture and store externally-sourced computable data (e.g., laboratory results, telemetry, medication details).",
"derivedFrom" : "EHR-S_FM_R1.1 DC.1.1.3.1#9"
},
{
"extension" : [
{
"url" : "http://hl7.org/ehrs/StructureDefinition/requirements-dependent",
"valueBoolean" : false
}
],
"key" : "EHRSFMR2.1-CPS.2.2-04",
"label" : "CPS.2.2#04",
"conformance" : [
"SHALL"
],
"conditionality" : false,
"requirement" : "The system SHALL provide the ability to capture and store externally-sourced standards-based structured, codified data.",
"derivedFrom" : "EHR-S_FM_R1.1 DC.1.1.3.1#11"
},
{
"extension" : [
{
"url" : "http://hl7.org/ehrs/StructureDefinition/requirements-dependent",
"valueBoolean" : false
}
],
"key" : "EHRSFMR2.1-CPS.2.2-05",
"label" : "CPS.2.2#05",
"conformance" : [
"SHOULD"
],
"conditionality" : false,
"requirement" : "The system SHOULD provide the ability to capture and store laboratory test data as discrete data elements (e.g., test name, laboratory sample status, date/time of collection, test results, original test units, laboratory panel name, pre-defined testing conditions met indicator, specimen identifier, reference range lower limit, reference range upper limit, laboratory identifier, abnormal flag, and clinical significance indicator)."
},
{
"extension" : [
{
"url" : "http://hl7.org/ehrs/StructureDefinition/requirements-dependent",
"valueBoolean" : false
}
],
"key" : "EHRSFMR2.1-CPS.2.2-06",
"label" : "CPS.2.2#06",
"conformance" : [
"SHOULD"
],
"conditionality" : false,
"requirement" : "The system SHOULD provide the ability to capture and store externally-sourced clinical documentation as structured data, where appropriate, including the original, updates and addenda."
},
{
"extension" : [
{
"url" : "http://hl7.org/ehrs/StructureDefinition/requirements-dependent",
"valueBoolean" : false
}
],
"key" : "EHRSFMR2.1-CPS.2.2-07",
"label" : "CPS.2.2#07",
"conformance" : [
"SHOULD"
],
"conditionality" : false,
"requirement" : "The system SHOULD provide the ability to capture and store health-related data from non-medical devices (e.g., digital camera or sound recorder)."
},
{
"extension" : [
{
"url" : "http://hl7.org/ehrs/StructureDefinition/requirements-dependent",
"valueBoolean" : false
}
],
"key" : "EHRSFMR2.1-CPS.2.2-08",
"label" : "CPS.2.2#08",
"conformance" : [
"SHOULD"
],
"conditionality" : false,
"requirement" : "The system SHOULD provide the ability to capture the original requisition ID number associated with an order."
}
]
}
XIG built as of ??metadata-date??. Found ??metadata-resources?? resources in ??metadata-packages?? packages.